This invention relates to management of network resources, and more particularly to a central directory for network resources.
It is standard engineering practice to generate a map of a computer network for the purpose of managing the network. Network management is ordinarily performed by software running on a server, where the software is referred to as a xe2x80x9cNetwork Management Platformxe2x80x9d. Well known commercial Network Management Platforms include the Hewlett Packard xe2x80x9copen viewxe2x80x9d product, the IBM xe2x80x9cNet Viewxe2x80x9d product, etc. Network Management Platforms ordinarily use Simple Network Management Protocol (SNMP) standard methods for creating a directory of SNMP capable devices. The Network Management Platforms locate all SNMP capable devices on the network. Information held in the Network Management Platform for each SNMP device includes, at a minimum, the network address of the device, the protocol needed to reach the device, and the type of device such as router, end station, bridge, etc.
It is desirable for users of data link switching routers (DLSW) routers, which forward packets according the protocol described in RFC 1795, to construct a map of the DLSw routers. RFC 1795 stands for xe2x80x9cRequest For Commentsxe2x80x9d Number 1795, published by the Internet Engineering Task Force (IETF) in April 1995, and available at the IETF website at the URL www.ietf.org. All disclosures of RFC 1795 are incorporated herein by reference. As additional references are made hereinbelow to various RFC documents, it is to be understood that they refer to xe2x80x9cRequest for Commentsxe2x80x9d of the IETF, and that they are available at the IETF web site.
A map of the DLSw routers, ideally, gives the topology of the DLSw devices, gives the address of each DLSw device, and in many cases gives important management information such as the types of encapsulation being forwarded by the router, the number of errors recorded by the router, the data rates (bytes or packets per second, etc.) at any particular time arriving at the router, etc. Detailed information which is valuable to management of a DLSw router network is not ordinarily available in the entries of a Network Management Platform. Accordingly, a DLSw router management function must use a two level polling operation in order to utilize a standard Network Management Platform.
The two level polling operation requires that the Network Management Platform first polls all SNMP capable devices in order to build up its directory. The DLSw router management tool must then obtain the network address of all devices in the Network Management Platform directory, and using that address send each device a polling message asking if the device is a DLSw router. The directory may contain thousands of SNMP capable devices scattered throughout the network, and only a few hundred of these devices may be DLSw routers. Thus only about one in ten (perhaps only one in a hundred) of the polling messages sent out by the DLSw router management tool is useful, and the other nine to ninety nine out of a hundred polling messages waste network bandwidth.
An alternative to using a two level polling system in connection with a Network Management Platform is to have xe2x80x9cseedxe2x80x9d routers configured in the DLSw router network. A seed router has the address of all xe2x80x9cpeerxe2x80x9d DLSw routers: Often the seed and peer routers are logically arranged in a hub and spoke topology, with the seed router at the hub and connected logically with the various peer routers connected as spokes. The seed router can then obtain detailed information about thexe2x80x9cspokexe2x80x9d peer routers. The seed router then constructs maps of the DLSw network by polling its peer routers, and can include as much detailed information as the user desires on the maps.
However, a disadvantage to the seed router is that many of the peer routers on the spokes of the seed router have other peer routers which are not logically connected to the seed router. Thus two classes of routers are introduced, those connected to the seed router, and those not connected. Protocols must be developed to handle various exceptions. Accordingly, the seed router has no direct way of knowing about these further distant DLSw routers, and cannot include them in the maps which it constructs. A solution to this difficulty is for the spoke peer routers of the seed router to forward management messages from the seed router. However, this arrangement increases the complexity of the DLSw router management system.
A further standard engineering practice which is used to build a database of specialized devices is to have the device log into an account maintained on a server, and then to have a person enter verification data such as a password to establish the connection. The server then maintains a list of all verified connections as the database. For example, the specialized devices may be desktop computers and the verified connections may be to a network ""server which provides connectivity between the desktop computers and a computer network. The list of verified connections to the network is then maintained as a database in the server. However, this method of using a verified connection to help build a database of devices is not suitable for building a database of routers. Topologically, routers do not log into a central server to establish a network connection, rather, in contrast, the routers are links in the network. That is, routers connect various local area networks (LANs) together, connect the LANs to wide area connections, etc. Also, a router does not have a person enter a password to establish a verified account in a server. Therefore, the verified account method of building a list of devices on a server is unsuitable for establishing a database of routers.
For routers using any protocol, in addition to the DLSw example, there is a need to create a topological map of the network connection of the routers. Each router will normally utilize a particular protocol, or perhaps a router may be capable of using several different specialized protocols such as the DLSw example. In any case, the Network Management Platform can be used to create the topological map and show the protocols is used by each router, but again two levels of polling are required. In the first level of polling, the Network Management Platform makes a list of SNMP capable devices, and in the second level of polling, each of these devices is sent a message asking if it supports a specific type of specialized routing protocol. Also, in each case, a seed router can be set up to develop a list of specialized routers, but then the same limitations of the hub and spoke connections create complexity in the system.
There is needed a method and apparatus to provide a complete management system for specialized routers, such as for example DLSw routers. The method and apparatus should avoid the waste of network bandwidth which occurs when two levels of polling are used by a standard Network Management Platform, and should avoid the complexity introduced by use of seed routers.
A complete management system for specialized routers such as, for example, DLSw routers is provided. The management system avoids the waste of network bandwidth which occurs from use of two levels of polling as used by a standard Network Management Platform, and also avoids the complexity introduced by use of seed routers.
The management system uses, for example, an LDAP server to maintain a DLSw Directory. Whenever a DLSw router is booted, the DLSw router sends a registration message to the LDAP Server giving the network address of the DLSw router. The LDAP Server then maintains a directory of all DLSw routers in the network (the DLSw Directory). The information maintained in the DLSw Directory has at least the network address of each DLSw router, and it receives at least this amount of information from the registration message received as the router is booted up.
Also, at a later time, the Network Management Application sends a message to the routers in the directory requesting further information. The routers then return this further information to the DLSw Directory. The further information comprises data such as: the types of encapsulation being received and routed by the router; the data rate in bytes per second or packets per second; the errors reported to the router; the errors detected by the router; the number of packets routed to each destination router; the number of routed packets of each type of encapsulation detected; the time at which any particular information was written into the DLSw Directory; etc. This further information may be requested from the DLSw routers listed in the DLSw Directory on a timed basis, for example, request messages may be transmitted on a timed interval so that the DLSw Directory can monitor data rates and loss rates in real time.
In the event that the directory: service does not return an ACK message within a timeout time interval, the router transmits an inquiry message to peer routers. A peer router answers the inquiry message with a message containing an address of a directory service of routers. The router then sends a registration message, using the received address, to the directory service.